Software Architecture Constraints as Customizable, Reusable and Composable Entities

International audienceOne of the major advantages of component-based software engineering is the ability for developers to reuse and assemble software entities to build complex software. Whereas decomposition of software into components has been and is largely addressed for what concerns the business (functional) part of applications, this is not yet the case for what concerns their documentation (non-functional) part. In this pa- per, we propose a new and original solution to express component-based software non-functional documentation, and we will focus more espe- cially on architecture constraints, which formalize parts of architecture decisions, as executable, customizable, reusable and composable build- ing blocks represented by components. Component-based applications using business and constraint components can be modeled with CLACS, a dedicated ADL which is also introduced in the paper. Architecture constraints can be executed at design-time within CLACS. CLACS is implemented as a plugin in the Eclipse IDE

Preserving architectural choices throughout the component-based software development process

Abstrac

Selection of Composable Web Services Driven by User Requirements

International audienceBuilding a composite application based on Web services has become a real challenge regarding the large and diverse service space nowadays. Especially when considering the various functional and non-functional capabilities that Web services may afford and users may require. In this paper, we propose an approach for facilitating Web service selection according to user requirements. These requirements specify the needed functionality and expected QoS, as well as the composability between each pair of services. The originality of our approach is embodied in the use of Relational Concept Analysis (RCA), an extension of Formal Concept Analysis (FCA). Using RCA, we classify services by their calculated QoS levels and composability modes. We use a real case study of 901 services to show how to accomplish an efficient selection of services satisfying a specified set of functional and non-functional requirements

Combining Exception Handling and Replication for Improving the Reliability of Agent Software

Abstract. Exception handling and replication are two complementary mechanisms that increase software reliability. Exception handling helps programmers in controlling situations in which the normal execution flow of a program cannot continue. Replication handles system failures through redundancy. Combining both techniques is a first step towards building a trustworthy software engineering framework. This paper presents some of the results from the Facoma project. It proposes the specification of an exception handling system for replicated agents as an adaptation of the Sage proposal. It then describes its implementation in the Dimax replicated agent environment

Automated architectural component classification using concept lattices

While the use of components grows in software development, building effective component directories becomes a critical issue as architects need help to search components in repositories. During the life-cycle of component-based software, several tasks, such as construction from scratch or component substitution, would benefit from an efficient component classification and retrieval. In this paper, we analyze how we can build a classification of components using their technical description (i.e. functions and interfaces) in order to help automatic as well as manual composition and substitution. The approach is implemented in the CoCoLa prototype, which is dedicated to Fractal component directory management and validated through a case study.Laboratorio de Investigación y Formación en Informática Avanzad

Software Architecture: Architecture Constraints

International audienceIn this chapter, we introduce an additional, yet essential, concept in describing software architectures : architecture constraints. We explain the precise role of these entities and their importance in object-oriented, component-based or service-oriented software engi-neering. We then describe the way in which they are specified and interpreted. An architect can define architecture constraints and then associate them to architectural descriptions to limit their structure, and for ultimately making persistent a certain level of quality. These constraints enable us to enforce adherence to a particular architecture pattern or style so as to ensure a certain level of maintainability. By interpreting these constraints, we are able to check whether these patterns/styles are respected, after the evolution of architecture descriptions. We present a state of the art on the current techniques and languages for ex-pressing these constraints. We then introduce our recent research, where we have developed languages for expressing these constraints on architectures of object-oriented, component-based and service-oriented applications. We will use different examples of architecture constraints representing known patterns and styles, like the Pipe and Filter architecture style and the Service Facade or Model-View-Controller architecture patterns, to illustrate these works. We conclude this chapter with a summary of some of the open questions which have given rise to ongoing research about this concept of architecture constraints

Contractualisation de l'évolution architecturale de logiciels à base de composants : Une approche pour la préservation de la qualité

Among all activities in the maintenance process, application understanding before evolution, and checking its progression and non-regression after evolution are by far the most expensive. In this thesis, I present an approach which aims at reducing costs associated to these two activities for component-based applications. In this approach, links unifying quality attributes of the application to architectural decisions are formally documented. The definition of these links is made at every phase in the life cycle. I developed an environment for evolution assistance, which uses this documentation. It ensures on the one hand that this documentation is updated, and on the other it notifies application evolvers the possible effects of her/his changes on quality requirements. This documentation forms thus a contract, said an evolution contract. It represents an agreement between the application architect and its evolver. The first should make explicit her/his design decisions, in the form of a set of constraints that should be respected during development and evolution. The second should respect this contract in order to gain the guaranty of preserving initial quality requirements. This allows mainly to reduce costs associated to regression testing at the non-functional aspect. This documentation is used for tracing all architecture decisions throughout a software development process. It is possible thus to check in a given phase of this process, the nonalteration of decisions made in upstream phases. I proposed a tool which allows to transform to a unique representation, and then evaluate, architecture constraints defined during different phases. This traceability of decisions has as a goal to make persistent quality attributes, which are origins of these decisions, throughout the phases of a software life cycle.De toutes les étapes qui constituent le processus de maintenance, l'étape de compréhension d'une application avant son évolution, et l'étape de vérification de sa progression et de sa non régression aprés évolution sont de loin les plus coûteuses. Dans cette these, je présente une approche qui diminue les coûts associés a ces deux étapes, pour des applications conçues à l'aide de composants. Dans cette approche, les liens unissant les attributs qualité d'une application et les décisions architecturales sont documentés formellement. La définition de ces liens se fait a chaque étape du cycle de vie de l'application. J'ai développé un environnement d'assistance à l'évolution, qui exploite cette documentation, pour d'une part, garantir sa mise a jour et d'autre part, notifier au développeur les effets possibles sur les exigences qualité des changements architecturaux proposés. Cette documentation forme ainsi un contrat dit d'évolution. Il s'agit d'un accord entre l'architecte de l'application et le responsable de son évolution. Le premier doit expliciter ses décisions de conception, sous la forme d'un ensemble de contraintes, afin qu'elles puissent être respectées lors du développement et de l'évolution. Le second doit respecter ce contrat afin de bénéficier d'une garantie de préservation de la qualité initialement requise. Ceci permet, principalement, de réduire les coûts associés aux tests de non-régression sur l'aspect non-fonctionnel. Cette même documentation est utilisée pour tracer toutes les décisions architecturales tout au long du processus de développement d'un logiciel. Il est possible, ainsi, de vérifier, à une étape donnée du processus, la non-altération de toutes les décisions prises dans les étapes en amont. J'ai proposé un outil permettant de transformer vers une représentation unique, puis évaluer, les contraintes définies lors des différentes étapes. Cette traçabilité des décisions a pour objectif de rendre persistants les attributs qualité qui sont à l'origine de ces décisions, à travers toutes les étapes du cycle de vie d'un logiciel

A Practical Approach to the Measurement of Similarity between WSDL-based Web Services

International audienceSimilarity measurement between web services is a key solution to benefit from the reuse of the large number of web services freely available in the internet. This paper presents a practical approach that enables an effective measurement of web service similarity based on their interfaces descibed with WSDL. The approach relies on the use of multiple matching techniques and different semantic and structural similarity metrics. The measurement of similarity determines the best substitute for a failed web service. So, it serves as a good indicator of the substitutability relation and thus of the capacity for reuse. A support tool, implementing the approach, is also presented with some experimental results conducted on real-world web services

Processing the Evolution of Quality Requirements of Web Service Orchestrations: A Pattern-Based Approach

International audienceCurrently Web services remain one of the leading technologies for implementing components of service-oriented software architectures. One of the most frequent form of composi-tions of these entities is Web service orchestration. As any other software artifact, such service compositions are subject to an unescapable evolution (Lehman's first law of software evolution). Either for answering new user requirements, for adapting, for correcting or for enhancing the provided functionality or quality, an architect has to conduct some evolutions on the design of these artifacts. In this paper, we present a method which aims at helping software architects of Web service orchestrations in processing an evolution of quality requirements. This method introduces a template for describing quality evolution "intents". It then analyzes these intents and assists the architects in answering them by proposing some patterns. We consider in our work the postulate stating that quality can be implemented through patterns, which are specified with checkable/processable languages. Besides this, the method that we propose simulates the application of these patterns and notifies the architect with its consequences on the other implemented qualities